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These figures show the separation between the RNL control plane, the RNL user plane, the TNL control plane, and the 
TNL user plane. The IP protocols and the need for a TNL control plane protocol in the IP domain are yet to be 
determined so they are shown with question marks. 

The following statements concerning interworking can be made based on the discussion and examples above: 

1) IP and AAL2/ATM UTRAN nodes use different address and flow identification types. The appropriate types 
must be provided to the appropriate nodes when establishing a transport bearer. 

2) A release '99 SRNC will initiate q.aal2 connection signalling and expect a response when establishing a transport 
bearer. 

3) A release '99 DRNC will expect to receive q.aal2 connection signalling when a transport bearer is being 
established by the SRNC. 

4) A transport network interworking function is required in the transport network. This function could be 
implemented in a third node with both IP and AAL2/ATM interfaces, for example. 

6.10.5 ATM/IP Interworking solution proposals. s 
6.10.5.1 Bearer control proposal using IETF SIP/SDP 

For exchanging transport layer information between IP UTRAN nodes, the RNL signalling should be used (RANAP, 
RNSAP, NBAP) without a Transport Network Control Protocol. 

For establishing transport connections between an IP UTRAN node and an ATM UTRAN node, a Transport Network 
Layer interworking function should be used in the transport network. This function would be implemented in a third 
node (such as an RNC) that has both ATM and IP interfaces. 

In order to interwork with the q.aal2 signalling used by the AAL2/ATM node, an IP ALCAP will be used. 

\ 

6.10.5.1.1 Description 

It is proposed to use Session Initiation Protocol (SIP) signalling with Session Description Protocol (SDP) parameters. 
SDP [58] supports both IP and ATM parameters. SIP [57] is proposed since it is an IETF signalling protocol and is used 
to carry SDP. 



Since a node must know what type of interface to communicate with, a Network Type parameter should be added to the 
RNL signalling. The following table shows how the Network Type parameter is used. 



R'99 


R5IP 


R5 ATM 


Action 


SRNC 


DRNC 




R5 DRNC knows the SRNC is R'99 because of missing transport parameters in 
RL setup req. R5 IP RNC does interworking steps. 


DRNC 


SRNC 




SRNC sends IP transport parameters that R'99 DRNC will ignore. SRNC must 
know that it is receiving ATM parameters. Absence of network type in response 
will indicate that it is R'99. R5 IP RNC does interworking steps. 


SRNC 




DRNC 


R5 DRNC knows SRNC is R'99 because of missing transport parameters in RL 
setup req. 


DRNC 




SRNC 


SRNC sends ATM network type parameter that R'99 DRNC will ignore. SRNC 
must know that it is receiving ATM parameters from DRNC. Absence of network 
type will indicate that it is R'99. 




SRNC 


DRNC 


SRNC sends IP transport parameters. SRNC must know that it is receiving ATM 
parameters. It can know this from the network type parameter in DRNC response. 
SRNC then performs interworking steps. 




DRNC 


SRNC 


SRNC sends ATM network type. R5 DRNC knows its ATM from the network type 
and performs interworking steps. 



6.10.5.1.2 Bearer control between IP and ATM nodes signalling examples 

The following figures provide signalling diagrams that show how the interworking can be achieved with this proposal. 
The Iur is shown as an example. UDP ports are shown for connection identifiers as an example. 
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Figure 6-38: Interworking between an AA2/ATM SRNC and an IP DRNC 

NOTE 1 : The rel '99 SRNC sends radio link setup. There is an SCTP Signalling Gateway for interworking the 
SCTP/IP signalling to ATM signalling. 

NOTE 2: The IP DRNC node responds with ATM transport parameters, the IP DRNC must have both ATM and 
IP addresses assigned to it. 

NOTE 3: The SRNC uses q.aal2 signalling to establish a connection towards the DRNC based on the address 
received in the RL Setup Response. The TNL IW node is along the route to the DRNC. 

\ 

NOTE 4: When the TNL IW function receives the q.aal2 set up message it determines that the destination node is 
an IP node. 

NOTE 5: The TNL IW function translates the ATM address to the IP address for the DRNC and sends a SIP Invite 
message to the IP DRNC. The Invite message includes the IP address and UDP port for traffic toward the 
TNL IW node. Also included is the binding ID so that the DRNC can correlate the transport signalling 
with the RNL signalling. 

NOTE 6: The IP DRNC responds to the Invite message. Included in the response message is the IP address and 
UDP port for traffic towards the IP DRNC. 

NOTE 7: When the TNL IW node receives the Response message it sends the q.aal2 confirmation message to the 

ATM SRNC. \ 

NOTE 8: To release the connection, the SRNC sends a q.aal2 Release Request. 

NOTE 9: When the TNL IW function receives the request it sends a SIP Bye Request to the IP DRNC. 

NOTE 10: The IP DRNC responds to the Bye Request and when the TNL IW function receives it, it sends the q.aal2 
Release Confirm. 
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Figure 6-39: Interworking between an AA2/ATM SRNC and an IP DRNC 

NOTE ll:The rel 4 SRNC sends radio link setup. An SCTP Signalling Gateway is used for interworking the 

SCTP/IP signalling and ATM signalling. The Setup message includes IP address, UDP port, and network 
type that will be ignored by the rel'99 DRNC. 

NOTE 12:The ATM DRNC node responds with the ATM transport parameters. 

NOTE 13:The SRNC sends a SIP Invite message to the TNL IW node. It includes the IP address and UDP port to be 
used for traffic towards itself. It also includes the ATM parameters received from the ATM DRNC so that 
the TNL IW function can establish an AAL2 connection with the ATM DRNC. 

NOTE 14: The TNL IW function initiates a q.aal2 establish request based on the parameters received from the ^ 
SRNC. 

NOTE 1 5: The ATM DRNC responds to the q.aal2 establish message. 

NOTE 16: When the TNL IW node receives the establish confirm message is sends a SIP response message to the IP 
SRNC. The response includes the IP address and UDP port used for traffic towards itself. 

NOTE 1 7:To release the connection, the SRNC sends a SIP Bye Request. 

NOTE 18: When the TNL IW function receives the request it sends a q.aal2 Release Request to the ATM DRNC. 
NOTE 1 9: The ATM DRNC responds to the Release Request. 

\ 

NOTE 20: When the TNL I W function receives it, it sends SIP response. 

6.10.5.1 .3 Use of SIP for Interworking between UTRAN ATM interfaces and UTRAN IP 

interfaces 



6.10.5.1.3.1 



6.10.5.1.3.1.1 



Description 

Inter Working Problem Summary 



It is required that interworking be possible between an IP UTRAN node (or MSC) that does not have any ATM 
interfaces and an ATM UTRAN node (or MSC). The motivations for this requirement are described in clause 5 
of the present document. \ 
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6.10.5.1.3.1.2 Approach/Aims 

The solution to the Interworking requirement should be such that there is a minimum set of requirements placed on the 
IP node. The IP node should as much as possible be able to act as if it is talking to another IP node. A Signalling 
Gateway is assumed for interworking the SCTP/IP signalling to ATM signalling. 

The TNL-IWF should receive either an Q.AAL2 establish request or an SIP Invite request message and be able to 
generate the other message based on the information that is in the message and a table of associations. The IP node 
should not need to make any ATM configuration decisions. Any ATM (AAL2) configuration should be done by the 
TNL-IWF. 

6.10.5.1.3.1.3 Using SIP as a Transport Bearer Signalling Protocol 

SIP 0 is a protocol that is specifically designed for the establishment of IP sessions for many different types of 
applications. It is an IETF protocol developed by the MMUSIC working group for creating, modifying and terminating 
sessions. SIP invitations contain session descriptions that allow participants to agree on a set of compatible session 
parameters. The session descriptions are described using SDP 0.SIP has scope for much more functionality than is 
required here, and is aimed for use as a multimedia session control protocol. However, a basic implementation of SIP, 
carefully defined so as to unambiguously describe the usage of the protocol for this application would meet the 
requirements for an IP ALCAP. 

6.10.5.1.3.1.4 Implementation 

Compliance with SIP places some requirements on the TNL-IWF and the communication between the TNL-IWF and 
the IP UTRAN (or MSC) Node. 

6. 10.5. 1.3*11. 4.1 ACK message 

In addition to the Invite request and Response messages, an ACK message is required by SIP to confirm the session. In 
clause 6.5 of [ 1 ] there should be an ACK message after receipt of the SIP response message for figures 30 and 3 1 . The 
ACK message should always be in the same direction as the original Invite Request message. 

The corrected diagrams and associated description are shown below: 
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Figure 6-40: Interworking between an AAL2/ATM SRNC and an IP DRNC 

NOTE 1: The rel *99 SRNC sends radio link setup. There is an SCTP Signalling Gateway for interworking the 
SCTP/IP signalling to ATM signalling. 

NOTE 2: The IP DRNC node responds with ATM transport parameters. The IP DRNC must have both ATM and ^ 
IP addresses assigned to it. 

NOTE 3: The SRNC uses q.aal2 signalling to establish a connection towards the DRNC based on the address 
received in the RL Setup Response. The TNL IWF is along the route to the DRNC. 

NOTE 4: When the TNL IWF receives the q.aal2 set up message it determines that the destination node is an IP 
node. 

NOTE 5: The TNL IWF translates the ATM address to the IP address for the DRNC and sends a SIP Invite 

message to the IP DRNC. The Invite message includes the IP address and UDP port for traffic toward the 
TNL IWF. Also included is the binding ID so that the DRNC can correlate the transport signalling with 
the RNL signalling. 

NOTE 6: The IP DRNC responds to the Invite message. Included in the response message is the IP address and \\ 
UDP port for traffic towards the IP DRNC. 

NOTE 7: When the TNL IWF receives the Response message it sends the q.aal2 confirmation message to the ATM 
SRNC. It also sends an SIP ACK message to confirm the IP bearer connection. 

NOTE 8: To release the connection, the SRNC sends a q.aa!2 Release Request. 

NOTE 9: When the TNL IWFreceives the request it sends a SIP Bye Request to the IP DRNC. 

NOTE 10: The IP DRNC responds to the Bye Request and when the TNL IWF receives it, it sends the q.aal2 
Release Confirm. 
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Figure 6-41: Interworking between an AAL2/ ATM SRNC and an IP DRNC \ 

NOTE 1 1 :The rel 5 IP SRNC sends radio link setup. An SCTP Signalling Gateway is used for interworking the 

SCTP/IP signalling and ATM signalling. The Setup message includes IP address, UDP port, and network 
type that will be ignored by the rer99 DRNC. 

NOTE 12:The ATM DRNC node responds with the ATM transport parameters. 

NOTE 13:The SRNC sends a SIP Invite message to the TNL IWF. It includes the IP address and UDP port to be 

used for traffic towards itself. It also includes the ATM parameters received from the ATM DRNC so that 
the TNL IWF can establish an AAL2 connection with the ATM DRNC. 



NOTE 14:The TNL IWF initiates a q.aal2 establish request based on the parameters received from the SRNC. 
NOTE 15:The ATM DRNC responds to the q.aal2 establish message. 

NOTE 16: When the TNL IWF receives the establish confirm message is sends a SIP response message to the IP 
SRNC. The response includes the IP address and UDP port used for traffic towards itself. The IP SRNC 
then confirms with an SIP ACK message. 

NOTE 17:To release the connection, the SRNC sends a SIP Bye Request. 

NOTE 1 8: When the TNL IWF receives the request it sends a q.aal2 Release Request to the ATM DRNC. 
NOTE 19:The ATM DRNC responds to the Release Request. 
NOTE 20: When the TNL IWF receives it, it sends the SIP response. 



i 



6.10.5.1.3.1.4.2 



Communication of endpoint information and session identification 



The signalling shown in clause 6.10.5.1.3.1.4.1 shows the SIP Invite Request message being used to pass certain 
parameters. These parameters are required to indicate the endpoints of the session being established. The following 
clauses define the use of the SIP fields and SDP parameters to be used in these SIP messages. 
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6.10.5.1.3.1.4.2.1 SIP header fields 



SIP messages are structured in a HTTP like way as defined in the SIP RFC [57] with a number of mandatory and 
optional fields. The mandatory fields (ie; they must be present in a SIP message) are: 



SIP header 


Contains 


Use in UTRAN 


Allow: 


1#Method 


only required in a 405 response 
message 


Call-ID: 


<session identifier^ 


The binding id is communicated 
here 


Contact: 


"sip:" <username>@<host> [ ":" 
<port> ] 


Username=soufce E164 address 
Host = src IP address or domain 
name 

Port = source SCTP port 


Content length: 


<length in octets> 


Length in octets of the message 


Content Type: 


<media-type> 


"application/sdp" 


Cseq: 


<sequence number> <method> 


Sequence number < 2**31 
Eg: Cseq: 471 1 INVITE 


From: 


w sip: M <usemame>@<host> [ ":" 
<port> ] 


Username=source E1 64 address 
Host = src IP address or domain 
name 

Port = source SCTP port 


To: 


"sip:" <usemame>@<host> [ ":" 
<port>] 


Username= destination E164 
address 

Host = destination IP address or 
domain name 

Port = destination SCTP port 


Via: 


<protocol-sent> <source ip> ":" 
<port> 


Protocol-sent= w SIP2.0/SCTP n 
Source ip = src IP address 
Port = src port address 



The Call-Id along with the From and To fields constitutes a Call leg. 

Other fields are optional and should not be mandated for the UTRAN application. 

6.10.5.1.3.1.4.2.2 SDP parameters 

The following SDP parameters are mandatory (must be present) as according to RFC 2327. 

- V - version of SDP. This should be set to zero. 

- O - this information represents the identity of the sender of the message. Username is left as "-" when the 
concept of users is not supported by the application. The session id needs to be a globally unique identifier that 
can be generated by any mechanism(ie random number, network time protocol, etc). For the UTRAN, this value 
will be set to the Binding ID received via the RN protocol(ie RNSAP/NBAP/RANAP). Version here refers to the 
version of the message and must be incremented each time(recommendatiori is to use an NTP timestamp). The 
network type is IN for internet and the address type is IP6 or IP4. The Address is the origin's address: ^ 

- S - this is an arbitrary string to associate with the session. 

- T - this is the time of the session. With the stop time set to zero indicates that the session is not bounded. The 
start time must be specified however (otherwise the session is regarded as permanent). 

- E - email address. The email address of the source (Inviter). Either this field or the p field (phone number) 
MUST be sent to comply with the SDP protocol. This field may be used to send the same information as the 
"contact" field in the SIP header. 

All other SDP parameters are optional according to [58]. The following parameters however are required and defined as 
follows for the UTRAN application of the SIP protocol as an IP ALCAP. 

1) C=IN IP6 <src IP6address> or, for Ipv4 option: c= IN IP4 <srcIP4address> 

2) this is information associated with the connection. Essentially it is a description of the network layer address that 
must be used to send data to. 
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M= application <udpport> udp/<IuxFP> <value> 

3) describes the media used for the session and provides the transport address. For this application, the media is an 
"application", will use a udp port assigned by the sender of the message, a transport protocol field (either IuFP, 
IurFP or IubFP) and a fmt type must be chosen. Values 96-127 are user definable for fmt type. 

A=fmtp: <value> <parameters> 

4) zero or more media attribute lines. This attribute is the main mechanism available in SDP to allow the extension 
of SDP and the tailoring of its use for particular applications. <value> should match with <value> in the m= line. 
<parameters> can be used to convey information describing the format of the media. In the case of the UTRAN 
application, this is proposed to convey some of the service requirements of the payload. This will consist of nine- 
parameters as follows: . 4 

- maximum FP-DU size(Framing Protocol Data Unit packet size including FP headers); 

- average FP-DU size; 

- maximum bit rate; 

- average bit rate; 

- path TYpe. 

These parameters are calculated based on the requirements of the RNL on the TNL as specified in the 3GPP 
specifications for the RNL and must be given for both uplink and downlink. The actual format of this message for the ^ t 
UTRAN application is: 

a=fmtp: <value> MaxSizeUp AvSizeUp MaxRateUp AvRateUp MaxSizeDn AvSizeDn MaxRateDn AvRateDn, 
PathType 



where <value> is as previously defined and: 



MaxSizeUp 


Maximum FP-DU size for the uplink. 


AvSizeUp 


Average FP- DU size for the uplink 


MaxRateUp 


Maximum Bitrate for the uplink 


AvRateUp 


Average Bitrate for the uplink 


MaxSizeDn 


Maximum FP-DU size for the downlink 


AvSizeDn 


Average FP- DU size for the downlink 


MaxRateDn 


Maximum Bitrate for the downlink 


AvRateDn 


Average Bitrate for the downlink 


Path Type 


Path Type 



6^10.5.1.3.1.4.2.3 Example message 

An example SIP Invite request could be represented as the following: 
INVITE sip: A2EA2(5)Jputrannode2 .operator.net 
Via: SIP/2.0/SCTP 194.237.226.242:5062 

From: sip: A2EA1 (%iwfl .operator.net \ x 
To: sip: A2EA2ffiiputraimode2.operator.net 
Call-ID: <BIDD1> 
CSeq: 1 INVITE 

Contact: sip: A2EAl@iwfl .operator. net: 5 062 
Content-type: application/sdp 
Content-length: 141 



ETSI 



ETSI TR 125 933 V5.1.0 (2002-06) 



where: 

A2E A 1 = E 1 64 address of the ATM node 
A2EA2 = El 64 address of the IP node 

BIDD1 = Session Identifier communicated in RANAP(Binding ID) 
194.237.226.242 = IP address of the IWF 
iwfl .operator.net = domain name of the IWF 
Iputrannode2.operator.net = domain name of the IP R5 node 

6.10.5.2 Bearer Control proposal using a new protocol ("Q.IP-ALCAP"), \ 
optimised for concatenation with AAL Type 2 links 

The discussion of the TNL interworking functionality in clauses 6.10.2.2 and 6.10.4 shows that a transport network 
layer interworking functionality (TNL IWU) is needed as well as a signalling protocol for bearer control (IP-ALCAP). 

A standardized transport network control protocol is beneficial to operators that have multi-vendor environments and 
one interworking function may be used by several RNCs, although they are from different vendors. 

Also from the discussion in 6. 10.2.2 and 6. 10.4, it becomes clear that the interworking functionality is part of the TNL. 
According to the principles of 3GPP and in particular RAN WG3, specification of new TNL protocols should 
preferably be done within other groups, e.g. IETF or ITU-T. 

As depicted in figures 6-36 and 6-37, the TNL IWU uses Q.2630.2 for communication with the R99/Rel-4 UTRAN ^ 
nodes. In order to ease implementation of such TNL IWU, the bearer control protocol for the IP-part of the connection 
will be as close to Q.2630.2 as possible. Related activities where started in ITU-T/SGI 1 as ITU-T was found to be the 
suited organisation to specify this new bearer control protocol. 

Currently (March 2002), ITU-T has started to investigate the requirements for such protocol. As no name for the new 
protocol has been defined in ITU-T yet, we will use the term "Q.IP-ALCAP" in this section to refer to this approach. 

From perspective mentioned above, it is desirable that "Q.IP-ALCAP" fulfils the following requirements: 

• Highly consistent with Q.2630.2 due to implementation related reasons described above 

• Support of embedded E. 164 addresses or AESA variant of NSAP also for IP nodes (To allow IP nodes to address 
R99/Rel-4 ATM nodes) ^ 

• Support of the generic IP-QoS parameters as agreed in section 7.9 for solution (3), i.e. Bit rate, SDU size, TNL 
QoS Class 

The following subsections of 6.10.5.2 will give details on the "Q.IP-ALCAP" proposal. As ITU-T is working in parallel 
to 3 GPP TSG RAN WG3, additional information can be found in their documentation (the topic is handled in ITU-T 
SGI 1, Question 15). 
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Regarding the schedule of the work in ITU-T and 3GPP, it may be desirable to hold intermediate versions of "Q.IP- 
ALCAP" in 3GPP, until the final version of this protocol is approved by ITU-T SGI 1 . Details how to handle such 
intermediate specification are to be determined. 

6.10.5.2.1 Overall Scenario for "Q.IP-ALCAP" 

The following figure 6-41 a gives an overview on the application of "Q.IP-ALCAP" in IP/AAL2 interworking. It shows, 
the user plane of an "A2IP connection" which is the concatenation of AAL2 type links ("AAL2 link" in figure 6-4 la) * 
with an IP link ("A2IP link" in figure 6-41a). Figure 6-41a is exactly the scenario as depicted in TRQ.AAL2IP.iw [67] 
which was (according to [68]) accepted as a baseline text specifying requirements by ITU-T. 

In this scenario, "Q.IP-ALCAP" shall support the establishment, maintenance, modification, and clearing of IP links as 
part of a concatenation of AAL type 2 links with an IP link in a mixed AAL type 2 and IP environment. The IP part of 
such a concatenated link is denoted in the figure as "A2IP link" .The shaded area of figure 6-4 la thus also shows the 
scope of TRQ.AAL2IP.iw [67]. 




AAL type 2 network 




> 




Figure 6-41a: Scope of TRQ.AAL2IP.iw [67] 

Figure 6-4 lb gives additional details of the layering of the signalling protocols and visualises again the positions of 
served users in this scenario. The "A2IP Signalling" entities in figure 6-41 b denote the signalling endpoints for the 
"Q.IP-ALCAP". Note, that in the course of work on "Q.IP-ALCAP" the scope of an "AAL2 Served User" has been 
extended in a way that it can be the user of an AAL2 type signalling protocol or A2IP type signalling protocol. The 
primitives exchanged between an "AAL2 Served User" and an "A2IP signalling" entity will differ from the primitives 
described in Q.2630. 

Note: A draft Q.IP-ALCAP was provided for information in [69]. 
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Figure 6-41 b: Detailed Layering of Signalling for AAL2/IP Interworking |. 

The definitions corresponding to terms used in figures 6-4 la and 6-4 lb are: 

A2IP connection: The logical concatenation of one or more AAL type 2 links and A2IP links between an AAL type 2 
service endpoint and an A2IP service endpoint. From the perspective of a Q.2630.1and Q.2630.2 AAL type 2 service 
endpoint, an A2IP connection is seen as an AAL type 2 connection. 

A2IP link: The logical user plane communication facility between two A2IP nodes. An A2IP link is designated by a 
pair of IP address/port number combinations. 

A2IP node: An A2IP service endpoint or an A2 IP Interworking Unit. 

A2IP interworking function: Functions residing in a A2IP interworking unit providing the bridge between an AAL ^ 
type 2 signalling entity and an A2IP signalling entity. ■ 

A2IP Interworking Unit: Interworking unit providing the conversion from AAL type 2 bearer to IP bearer 
(RTP[59]/UDP[42] or UDP[42] only). The Interworking Unit terminates AAL type 2 links and A2IP links. There is no 
served user associated with an A2IP Interworking Unit. From UTRAN perspective, this unit is the Release 5 TNL 
Interworking Unit. 

A2IP service endpoint: A termination point of the IP part of an A2IP connection. There is an AAL type 2 served user 
associated with an A2IP service endpoint. 



AAL type 2 served user: The user of an AAL type 2 or A2IP signalling protocol. 

A2IP signalling protoc 1: Control plane functions for establishing and releasing A2IP connections and the 
maintenance functions associated with the A2IP signalling. 
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6.10.5.2.2 
Protocol Stack 



Protocol Stack for "Q.IP-ALCAP" 



As interworking between IP and ATM based RNCs appears only during the migration phase from an ATM based 
network to an IP based one and only at the boarder between the two network types, the interworking solution - and 
therefore the selected signalling protocol stack - should be straight-forward. 
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Figure 6-42: Protocol Stack for Transport Network Control Plane Interworking 

\ 

Figure 6-42 presents the proposed protocol stack within the transport network control plane. The Signalling Transport 
Converter on SCTP is defined in [53]. 

Benefits of this Protocol Stack 

The benefit of that protocol stack is, that most employed protocols are already in use inside the RAN and the additional 
specification work is low. Therefore a standardized interworking functionality can be easily introduced into the RAN 
without the necessity of new protocols. Services provided by AAL2 signalling entities are unchanged. The interworking 
unit itself can be based on an existing set of AAL type 2 service endpoints. 



6.10.5.2.3 



Example: Connection Establishment on lur 



This example shows transport bearer establishment and data on lur. This shows the case where the legacy RAN is the 
drift RNS. 
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/. RNSAP: RL Setup Request Q 



2. RNSAP: RL Setup Response [TLA^AIEA ; TA=BID] 



3. ERQ [NSEA=A2EA ; CEID ~ NULL ; 
ALC; OSAID ; SUGR - BID ; SSISU ; 



OSAID = "unknown " ; 
IP&ID- IP^c & UDP^J 



4. ERQ [CEIQ 
ALC 



6. ECF [DSAID ; OSAID ; fPE/D- IP IW{1 & UDP IW J 



ZIP/UDPflPw.'VOPnnJ 



10. IP/UDP [IP^c ; UDP^J 



; NSEA—A2EA ; DSAID = "unknown ' 
OSAID ; SUGR = BID ; SSISU] 



5. ECF [DSAID ; OSAID] 



8. AAL2 [PathlD ; CID] 



9. AAL2 [PathID ; CID] 



Figure 6-43: Connection Establishment on lur 

1) IP based RNC (serving RNS) initiates establishment of the radio link with RNSAP message Radio Link Setup 
Request. 

2) The legacy RNC node sends RNSAP message Radio Link Setup Response to the IP based RNC containing TLA 
and TA. TLA contains the ATM endpoint identifier of the ATM based RNC and TA contains an binding ID 
chosen form the ATM based RNC. 

3) The IP based RNC sends an Q.IP-ALCAP establishment request message (ERQ) to the IWU that contains the IP 
endpoint identifier (IP address and UDP port of the IP based RNC for the new link). The CEID will be set to \ \. 
NULL. 

4) The IWU acts as an AAL type 2 switch, but in addition it removes the IPEID and generates the CEID. 

5) The CN node sends the connection confirm message (ECF) to the IWU. 

6) The IWU acts as an AAL type 2 switch, but in addition it IPEID containing IP address and UDP port of the IWU 
for the new connection. 

7) The IP based RNC sends data to the IWU using the assigned IP address and UDP port. 

8) The IWU passes the data on to the ATM based RNC node using the established AAL2 connection. 

9) The ATM based RNC node sends data to the IWU using the established AAL2 connection. 

10) The IWU passes the data on to the IP based RNC using the assigned IP address and UDP port of the RNC. 



Connection release is simply the same as specified in [52]. Connection establishment initiated by the ATM based RNC 
works respectively. 



6.10.5.3 



IP-ALCAP based on Q.2630 



6.10.5.3.1 



Benefits 



AAL2 signalling Q.2630 is used as the ALCAP in Rel99, Rel4 and Rel5 ATM UTRAN nodes. So Q.2630 will be in 
Rel5 UTRAN irrespective of its presence in the Rel5 IP transport option. Q.2630 itself is expected to be a well-known \\ 
protocol (behaviour, performance, operation&management) by the time it is introduced in any Rel5 IP UTRAN. 

IP-ALCAP as a whole is introduced in Rel5 IP transport option only as the control protocol between the IP UTRAN 
node and the stand-alone ATM/IP interworking unit. In the case where no interworking is required, i.e., there are only 
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Rel5 IP nodes and no IP/ATM interworking unit, then the IP-ALCAP is not required either. Thus the presence of IP- 
ALCAP is tightly coupled to the presence of ATM transport between the two UTRAN nodes. 

It is explained in this contribution that the needed change to the Q.2630 for it to provide the IP-ALCAP functionality is 
small and specific to its application as the control protocol in the Rel5 IP TNL-IWU interface. Thus this change can 
well be specified by the involved 3GPP Working Group alone, without any need for any involvement of any 3GPP 
external standards organization. This aspect is attractive in the sense that it excludes all additional risk in 
schedule/availability of the needed capability. 

During the discussions in RAN WG3 it has been argumented that any new protocol that is introduced in Re5 IP 
transport should be an IETF protocol. However, the introduction of Q.2630 as the IP-ALCAP is to use an existing and 
well-established UTRAN protocol (also used in CN) instead of introducing any new protocol at all. 

6.10.5.3.2 IP-specific information in Q.2630 in Served User Transport (SUT) parameter 

All information that is conveyed in the control plane of the Rel5 IP TNL-IWU interface is only between the the peer 
termination points of the given interface. This is because of the following: 

1) IP-ALCAP in Rel5 is introduced only as the control protocol between the Rel5 UTRAN IP node and its 
corresponding stand-alone Interworking Unit (the 3 interworking alternative). 

2) In this interface there are no intermediate AAL2 switches nor any other intermediate IP- ALCAP-aware nodes. 

3) IP-ALCAP is not visible to the other side of the TNL-IWU, including any intermediate AAL2 switch there. 

The following figure depicts the scope and visibility of IP-ALCAP in Rel5 UTRAN. S 

Ftel5 UTRAN IP Node ATM UTRAN Node 




Figure 6-44: IP-ALCAP in Rel5 UTRAN: The scope 



6.10.5.3.2.1 Served User Transport parameter in Q.2630 

In Q.2630 [2] there is already today a parameter called Served User Transport (SUT). As defined in Q.2630, the SUT is 
a parameter "with significance to the served user only, therefore they shall not be examined by the nodal Junction 
[intermediate AAL2 switch]." Moreover, the SUT "carries the served user data that is transported unmodified to the 
destination served user. u The definition of SUT is similar in both existing Capability Sets, CS-1 and CS-2 of Q.2630 
and there is no reason foreseen for it to be excluded from the future Capability Sets (if any) either. 

The SUT parameter is very similar to the Served User Generated Reference parameter (SUGR), the major exception 
being that the SUT has variable length of up to 254 octets. The SUGR is used in Rel99/Rel4/ReI5 for the conveyance of 
the Binding ID between the two peer UTRAN nodes, in a similar fashion as it is now proposed for the IP related ^ 
parameters to be conveyed in SUT. 

The IP "bearer" establishment procedure between the Rel5 IP UTRAN node and the stand-alone IWU requires a two- 
way signalling message exchange (Request-Confirm). It is also required (preferable) that each end point can allocate the 
"bearer" termination point in its side. That is, both endpoints should be able to signal their IP address and UDP port to 
the other end point. This approach is in line with the principle adopted already in Rel99/Rel4 Iu-PS interface. In the 
current Q.2630 the SUT has been defined only in the Establish Request (ERQ) message. That is, SUT is available only 
in the forward direction. Application of SUT in IP-ALCAP requires that the parameter is present also in Establish 
Confirm (ECF) message. The addition of SUT in ECF can be considered a 3 GPP specific change and there an 
application specific change as it is needed only in the IP TNL-IWU interface. As the SUT as a parameter has already 
been fully defined in Q.2630 (parameter ID, compatibility rules, etc.), its inclusion in ECF is simply a copy from ERQ. 
As there are no intermediate AAL2 nodes between the Rel5 IP node and the TNL-IWU, its inclusion in ECF does not 
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generate any incompatibility issue either (in Q.2630 there is an inbui Id mechanism to cope with these issues, ref. 
below). 



6.10.5.3.2.2: 



Structure of information 



Below is the parameter format used in Q.2630 for all parameters. Parameter ID for Served User Transport is 
"00001000". Parameter compatibility is used for defining the behavior of the node when unrecognized information is 
received [table 7-20/Q.2630.1]. 



Header 



Payload 



Table 7-2/Q.2630.1 - AAL type 2 parameter format 



Parameter identifier 



Parameter compatibility 



Parameter length 



Fields 



Octets 

1 

1 
1 



Table 7-7/Q.2630.1 - Identifiers of the AAL type 2 message parameters (concluded) 



r AAL type 2 parameter 


Reference 


Acronym 


Identifier 


Served user transport 


7.3.8 


SUT 


00001000 



Table 7-15/Q.2630.1 - Sequence of fields in the served user transport parameter 



Field No. 


Field 


Reference 


1 


Served user transport 


7.4.18 



In the following there is the structure of the Served User Transport field as defined in Q.2630 [chapter 7.4.18]. 
Table 7-38/Q.2630.1 - Structure of the Served User Transport field 



! 8 I 


7 


6 I 5 I 4 I 3 


2 


1 


Octets 






Field length 






1 














Served user transport 





The length of the Served User Transport parameter is variable from 1 to 254 octets, allowing a reasonable capacity for 
any information exchange. 

It has already been agreed that a bearer in IP domain is identified by its UDP ports and IP addresses. Thus the 
information conveyed in SUT is, at least, the IP address and the UDP port of the originating node (the originator of the 
corresponding IP-ALCAP message). The structures of the corresponding fields are proposed to be as follows. 
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UDP Port Number 



Octets 
1 
2 



The UDP port Number has a fixed length of 2 octets: 



8 I 7 | 



J I i | 3_ 



Field length 



IP address 



Octets 
1 
2 



The IP address has a variable length of max. 1 6 octets (IPv6). Variable length allows the field to be used with IPv4 \ 
addresses as well (optional in Rel5 IP UTRAN). 

The traffic and QoS parameters can be conveyed in the following fields in the payload of SUT. 



! 8 


1 7 


1 6 


1 5 1 4 I 3 1 


2 


1 


Octets 


I TNL QoS Class 


1 


8 


7 


1 6 


1 5 | 4 I 3 1 


2 


1 


Octets 


Maximum bit rate in forward direction 


1 
2 


Maximum bit rate in backward direction 


3 
4 


8 


7 


1 6 


1 5 I 4 | 3 I 


2 


1 


Octets 


Average bit rate in forward direction 


1 
2 


Average bit rate in backward direction 


3 
4 



8 I 



6 15 14 13 
Maximum SDU size in forward direction 



Octets 
1 
2 
3 
4 



Maximum SDU size in backward direction 
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6 



1 



Average SDU size in forward dir ction 



Octets 
1 
2 
3 
4 



Average SDU size in backward direction 



The coding of the other existing parameters in ERQ and ECF should be kept as it has been defined in Q.2630. Only this 
way there is no other change needed than the introduction of SUT in Establish Confirm message. It is to be noted here 
that the AAL2 Service Endpoint Address (A2EA) parameter conveys now the address of the destination ATM UTRAN. 
node that was given in the corresponding xxxAP message. As the signalling bearer of IP-ALCAP is IP based, the IP 
address of the TNL-IWU is conveyed in the IP header instead of in IP-ALCAP itself. Those parameters that are not 
applicable in Rel5 IP TNL-IWU interface should be left out if their presence is optional or otherwise filled with a 
dummy value. 

In principle there are two ways of conveying the above defined information in the Served User Transport parameter. 
Either each element of information has its own identifier or the elements do not have any identifier but only length and 
value. In this proposal the elements of information do not have any identifiers and the length is included only in case of 
variable length element (IP address). This approach requires that the order of appearance of the elements is specified as 
well. With this arrangement the above mentioned elements take 35 octets from the available 252 octets of payload. 
Should there be any other IP TNL-IWU specific information that needs to be conveyed between the two nodes, this 
information can be conveyed in the similar fashion as above. 

6.10.5.4 Use of IETF RSVP for ATM/IP interworking 

This approach consist on the use of the Resource Reservation Protocol (RSVP) as the IP TNL control plane that allows: 

1) The signalling of the QoS parameters to the IWU (IP originated case) 

2) The application of the QoS signalled by Q.2630 (ATM Originated case) 

3) The simplification of the IWU. This would be reduced to an IWF integrated in a typical IP router, less expensive 
to operators and easier to provide by vendors and also making the UTRAN transport more standard to the 
classical IP transport, since RSVP is commonly implemented in the IP routers. 

RSVP [54] is a protocol designed for integrated services in Internet allowing the establishment of simplex IP sessions i 
for many different types of applications (it handles different flows with different QoS). The advantages of this protocol 
is that a limited number of messages are needed to define the behavior that is explained in the present document, 
together with the QoS orientation of RSVP. It also allows defining new objects where, in this case, the needed ATM 
parameters will be transferred to the IWU in order to be able to establish ATM connections. 

As basic operation, the TNL-IWU will receive either Q.2630 establishment requests or RSVP Path messages and be 
able to generate the appropriate messages on the other side with the information included in the received messages. 
Therefore, RSVP signalling is only valid between IP UTRAN node and IWU, and ATM signalling is valid between 
ATM UTRAN node and IWU. 

6.10.5.4.1 Working scenarios 

This clause covers the main scenarios including establishment and release of transport connections, including the issues^ 
derived from this kind of implementation. 

6.10.5.4.1 .1 ATM UTRAN Node initiated RL Setup procedure 

In this scenario an ATM SRNC (CRNC) sends a RL Setup Request message to an IP DRNC (Node B), which sends 
back a RL Setup Response message including SUGR (binding ID) and A2EA (Transport Layer Address) IWU among 
other parameters. 

The TNL messages are depicted in the figure below: 
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ATM 
SRNC 
(CRNC) 



IWU 



IP 

DRNC 
(NodeB) 



RL Setup Request 



RL Setup Response IA2EA_IWU. SUGftl 



ERQ (CID, OSAID, SUGR, A2EAJWU, LC, SSCS, PT]j Path ( SESSION, RSVP_HOP. TIME.VALUES, j 
,J SENDERJTEMPLATE, SENDER.TSPEC, DCLASS. SUGR] 

: « 



ECF 



Resv ( SESSION, RSVP.HOP, TIME.VALUES] j 

ath V SESSION. RSVP_HOP. TIME, VALUES. I 
feNDERJTEMPLATE. SENDERJTSPEC, DCLASS, SUGR] 



Resv rSESSION. RSVP_HOP. TIME_ VALUES^ 



DATA TRAN! 
! RL Deletion procedure 


IFER 


! RELICAUSE1 ^ 


PathTear [SESSION, RSVP_HOP] 




^ PathTear ("SESSION, RSVP.HOP] 


!^ RLCfl 





Figure 6-45: Interaction between ATM SRNC (CRNC) and IP DRNC (Node B) 



Procedure: 



1) Radio Link Setup procedure. In addition to the SUGR, PT (only in R5) and SSCS Information, the IP node sends 
the Transport Layer Address of the IWU in the RADIO LINK SETUP RESPONSE message. 



2) After RL Setup procedure is completed, SRNC (CRNC) sends an ERQ message to the IWU. 
3) 



Upon reception of ERQ message and after granting the admission of the new AAL2 connection, the IWU sends a 
PATH message to the DRNC (Node B) with the help of a table to convert ATM ports to IP addresses. This 
message will include the QoS parameters needed for the Admission control (SENDERJTEMPLATE, 
SENDERJTSPEC, DCLASS and SUGR), and additionally it may provide the DiffServ code points to use for the 
bearer flow (with the inclusion of the DCLASS object in the Path message). 

4) Upon reception of a Path message the DRNC (Node B) sends a RESV and a PATH messages to the IWU if no 
other session with the requested Binding-ID (SUGR) is set (note that a reservation is needed for each direction as 
well as a previous definition of the connection QoS by means of the PATH message). If any of these messages 
fail, a timer waiting for an incoming Path message in the IWU or the PathErr and ResvErr messages incoming to 
the IWU will make that SRNC (CRNC) and IWU consider the ERQ as failed. Also note that there is a need for a 
RNCJD to A2EA_IWU conversion in the DRNC database. ^ , 

5) Upon reception of the Path message, the IWU sends an ECF message to the SRNC (CRNC) and a Resv message 
to the DRNC (Node B). 

6) At this point data can be sent in both directions. Note that the RSVP PATH and RESV must be maintained 
periodically. 

7) The SRNC (CRNC) initiates the release of the transport connections with a REL message to the IWU. 

8) Upon reception of a Q.2630 Release Req message the IWU sends back the confirmation (RLC) to the SRNC 
(CRNC). It is up to the implementation whether the RSVP is released by means of a PathTear message or 
waiting for the refresh timers expiry. However, it is recommended to implement the Tear down messages, to 
speed up the release of the IP bearer. . 
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6.10.5.4.1.2 IP UTRAN Node initiated RL Setup procedure 

In this scenario an IP SRNC (CRNC) sends a RL Setup Request message to an ATM DRNC (Node B), which sends 
back a RL Setup Response message including SUGR and A2EA IWU among other parameters. 

The TNL messages are depicted in the figure below: 



ATM 
DRNC 
(Node B) 



IWU 



IP 
SRNC 
(CRNC) 



RL Setup Request 



RL Setup Response TA2EA. SUGR1 



Path [j SESSION, RSVP.HOP. TIME.VALUES, SENDERJTf MPLATE, 
S END E R_TS PEC , SUGR, t DCLASS, SUGR. A2EA, PT ] j 

: i 

! Resv ['SESSION, RSVP_HOP, TIME_VALUES] J 
. . jsj 

j Path ['SESSION, RSVP_HOP, TIME_VALUES, j 

J SFMHFR TEMPLATE. S FNDFR TSPRP. XlIfSR]^ 



ERQ [CID, OSAID, SUGR, A2EAJWU.PT, SSCS, PT] 
< 



Resv f SESSION. RSVP_HOP, 



TIME_VALUES] 



ECF 



KJ-- 



DATA TRANSFER 



H>0 



RL Deletion procedure 



REL ICAUSE1 



RLCM 



PathTear [ SESSION, RSVP_HOP1 



PathTcar [ SESSION, RSVP_HOP] 



Figure 6-46: Interaction between IP SRNC (CRNC) and ATM DRNC (Node B) 

Procedure: 

1) After RL Setup procedure is completed, SRNC (CRNC) sends a Path message to the IWU. This message will 
contain additionally to the RSVP PATH parameters, the DCLASS object, the SUGR, A2EA and PT information^ 
in a new RSVP Object. 

2) Upon reception of a Path message the IWU will respond with a Resv and a Path messages. 

3) Upon reception of a Path message the SRNC (CRNC) will send a Resv message to the IWU. 

4) Upon reception of a Resv message, the IWU will send an ERQ message to the DRNC (Node B). 

5) The DRNC (Node B) will respond with an ECF message to the IWU, completing the establishment. 

6) In this point data can be sent in both directions. Note that the RSVP Path and reservations must be maintained 
periodically. 

7) The SRNC (CRNC) initiate the transport layer connections by sending a PathTear message to the IWU. |j 

8) Upon reception of a PathTear message the IWU will send a REL message to the DRNC (Node B) to release 
ATM connection. 

9) The DRNC (Node B) will send back a confirmation message to the IWU (RLC), completing the ATM 
connection release. 

10) The IWU also sends a PathTear message to the SRNC (CRNC) in response to the previously received PathTear 
j message. 
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Advantages: 

- There is a direct signalling and application of the same QoS across the entire interface. This is possible because 
of the interworking function integrated in RSVP as well as the possibility to signal DiffServ Code Point inside 
RSVP. 

- There is no limitation on the IP side respective to the method of QoS to be applied, it is possible to use either 
RSVP or DiffServ. V 

Issues: 

- The IWU will have only one node associated to an ATM address + OSAID. This is to uniquely identify the IWU 
Transport Layer Address with an IP node. 

- In the DRNC (Node B) side there is a need for an RNC-ID to A2EAJWU database to perform the addresses 
conversion. The IWU ATM address is a "default gateway" for the IP node to address all the ATM nodes. 

- In the IWU side there is a need for an A2EA_IWU + OSAID to IP address database to perform the addresses 
conversion. 

- There is a need to define a new object in RSVP that carries all AAL2/ATM QoS related fields needed in the ^ 
procedure. 

- In case diffserv is used, the Path ID will be mapped to a DiffServ CP and the IWU will contain a table to map PT 
to diffserv CP. Here the DCLASS object will be used. 

- The IWU will have a timer that controls the PATH refresh procedure in order to release the ATM connection if 
any problem occurs in the IP side. 

6.10.5.4.1.3 RSVP considerations 

In this clause generic topics regarding RSVP such as Reservation Confirmation, traffic policing, recommended values 
for timers or security considerations are not covered. For more information about them please refer to [54]. 

The only modification in the RSVP protocol needed to make this solution feasible is the definition of a new object apar$ 
from the standardized ones (SESSION, RSVP_HOP, TIME_V ALUES , etc.) assigning an unused value for an object 
that will contain the ATM parameters needed to be passed to the IWU in order for it to establish the corresponding 
ATM connections towards the ATM UTRAN node. 

This new object must be defined according to the standard object format defined in [54]. Every object consists of one or 
more 32-bit words with one fixed header with the object length, the chosen Class-num and C-Type (a value unique 
within Class-num). After the header the content should be defined included the needed ATM parameters. 

6.10.6 Coexistence between Rel4 and R99 lur Control Plane using SUA 
protocol 

Clause 6.7.2 describes the option of SUA as IP based signalling User Adaptation Layer in lur Control Plane. 

It is clear that SUA provides seamless functions and services as SCCP (from RNSAP point of view), and also, as 
advantage, SUA is optimized to be used over SCTP/IP, providing e.g. SCCP-to-SCTP/IP address translation. See {26] 
for further details. 

6.10.6.1 Connecting an Rel4 RNC to a R99 RNC 

A way to interwork an Rel4 RNC to a R99 RNC is using signalling gateway, (this gateway can be embedded in the 
same physical equipment as an RNC) Using SUA, the RNSAP SAP is maintained for both TNL options since SCCP 
and SUA provide the same primitives and services to RNSAP, so no changes to RNSAP are needed to support both 
TNL options. With SUA, the RNL independence is maintained for Rel4 as in R99. 

\ 

The signalling gateway would perform the L2/L1 to AAL5/ATM/L1 conversion. In this case SUA does not add any 
interworking problem, since the signalling gateway performs the domain conversion from SCCP to SUA/SCTP/IP and 
vice versa. Also, it is noted that the signalling gateway could come from any vendor, since all protocol used in both 
ends of the SG are standardized. 
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